1. Field of the Invention
This invention relates to computer networks, and, more particularly, to the validation of Web resources such as Web content (data), Web applications, and Web services.
2. Description of the Related Art
The Internet, sometimes called simply “the Net,” is a worldwide system of computer networks in which a client at any one computer may, with permission, obtain information from any other computer. The most widely used part of the Internet is the World Wide Web, often abbreviated “WWW”, which is commonly referred to as “the Web”. The Web may be defined as all the resources (e.g., Web pages and Web sites) and users on the Internet that use the Hypertext Transfer Protocol (HTTP) or variations thereof to access the resources. A Web site is a related collection of Web files that includes a beginning file called a home page. From the home page, the user may navigate to other Web pages on the Web site. A Web server program is a program that, using the client/server model and HTTP, serves the files that form the Web pages of a Web site to the Web users, whose computers contain HTTP client programs (e.g., Web browsers) that forward requests and display responses. A Web server program may host one or more Web sites.
Web Services
As described above, the conventional Web model allows users to access Web resources (e.g., applications, services, and data) via an HTTP client program, such as a Web browser. A technology referred to as Web services has been developed to provide programmatic access to Web resources. Web services may be used to provide Web software developers programmatic access to Web resources including technology platforms (e.g., applications and services) and data (e.g., product catalogs and other databases) hosted on Web-connected computers such as Web server systems via a Web service interface. Generally speaking, a Web service interface may be configured to provide a standard, cross-platform API (Application Programming Interface) for communication between a client requesting some service to be performed and the service provider. In some embodiments, a Web service interface may be configured to support the exchange of documents or messages including information describing the service request and response to that request. Such documents, or messages, may be exchanged using standardized Web protocols, such as the Hypertext Transfer Protocol (HTTP), for example, and may be formatted in a platform-independent data format, such as eXtensible Markup Language (XML), for example.
FIG. 1 is a block diagram that illustrates an exemplary system configuration that provides a Web service interface, and shows the interaction between a Web service client and a Web service provider. In this example, a Web service interface 106 may be implemented on a server 130 coupled to Internet 100. This server 130 may be referred to as a “Web service provider”. Server 130, or alternatively one or more other servers coupled to server 130, may include one or more applications or services 108. Server 130 may be coupled to data storage 140 for storing information in database 142. Database 142 may include any type of data.
Server 120 may be coupled to Internet 100. Server 120 may host a Web service client 124. Web service client 124 may be configured to programmatically access application or service 108 of server 130 and/or database 142 via Web service interface 106. Note that Web service interface does not provide a “Web browser” interface, but instead provides a programmatic interface via an API through which at least some functionality of application or service 108 and/or at least some data in database 142 may be programmatically accessed by Web service client 124. Also note that server 120 may provide a Web site accessible to client(s) 122 via Web browsers, and Web service client 124 may be configured to access at least some functionality of application or service 108 and/or at least some data in database 142 of server 130 via Web service interface 106 to provide access to at least some functionality of application or service 108 and/or at least some data in database 142 via the Web site provided by server 120. Further, note that Web service client 124 may itself be another Web service.
To access an application, service or data provided by the Web service provider 130, Web service client 124 may send a request message to Web service interface 106 via Internet 100. This request message goes through the network and Internet infrastructures; through the Web service client 124's local network routers, switches, firewalls, etc., through the Internet backbone, to the Web service provider's local network, to Server 130, and then to Web service interface 106. Web service provider 130 may then process the request, for example by performing an indicated function(s) of application or service 108 or accessing indicated data in database 142. Web service interface 106 may then return results of the processing to the Web service client 124 in a response message via Internet 100, back through the local networks and Internet backbone.
Web Resource Validation
Web services, Web applications, and Web sites/Web pages that provide Web resources (applications, services, and/or data) on the Web may collectively be referred to as “Web entities.” Web software developers or other Web users may desire or require the validation of various Web resources provided by Web entities in request/response loops. For example, a Web software developer may be developing or testing an application that accesses a Web service by sending requests to the Web service's API to obtain information about products in a Web site's product catalog in responses from the Web service's API. The Web software developer may desire to validate that the content and/or format of an actual response received from the Web service corresponds to expected values and/or format for a response to the request that generated the actual response.
Conventionally, testing a request/response loop in an application requires the tester to call the remote Web entity under test, receive a response to the call, and then perform one or more tests to validate specific fields against expected results. Making calls to a remote Web entity under test may require the tester to have specific knowledge of the specific protocol of an API of the Web entity under test. A tester may, over time, desire or be required to perform testing of a number of different Web entities, each of which may have a specific API, thus requiring the tester to learn the specific protocols of each Web entity tested.
A response to a call the remote Web entity under test may be returned in a document with XPath-parseable content (e.g., XML, HTML, any dynamic language whose output is XML/HTML, etc.). Thus, testing the response may require the tester to have XPath capabilities and knowledge to be able to parse and reference items out of the document. XPath is a language that describes a way to locate and process items in documents by using an addressing syntax based on a path through the document's logical structure or hierarchy. When working with XPath, the tester may have to call in additional modules, parse the document within the XPath framework, and use the nomenclature of the specific XPath framework. This may be a complex, multi-step process, and may involve high-level coding. Conventionally, the client would have to perform multiple, complex steps to get to that point once the raw response is received from the Web entity under test. Further, as is the case for making calls to the remote entity under test, testing responses received from a remote Web entity under test may require the tester to have specific knowledge of the specific protocol of an API of the Web entity under test.